Challenges in Unifying Control of Middlebox Traversals and Functionality

Network services appliances, i.e., middleboxes, are a key component of enterprise networks. Through examination andmodification of network traffic, middleboxes help ensure security, optimize performance, and facilitate remote access. A diverse array of middleboxes exist, both in terms of functionality and vendor, requiring distinct, distributed configuration across the enterprise [8]. Furthermore, the network must be configured (physically or via routing changes) to direct traffic through the appropriate middleboxes. Including middleboxes in network topologies has become easier and more flexible with the advent of software defined networking (SDN). SDN enables middleboxes to be placed anywhere within the network while still ensuring that specific subsets of traffic traverse the desired set of middleboxes [3, 6]. SDN is especially useful formiddlebox deployments in clouds: tenants and providers can leverage SDN to direct traffic between application and middlebox VMs [4]. While SDN enables control overmiddlebox traversals, the configuration of the middleboxes themselves remains an outof-band activity. Each middlebox must be individually configured with the appropriate policies, rulesets, etc. Such distributed, manual configuration, separate from control over traffic forwarding, makes reasoning about and verifyingmiddlebox deployments challenging. Additionally, changes in network topology–which can occur frequently in overlays connecting VMs in the cloud–or changes in the underlying middlebox software/hardware–which can occur when enterprises move services from a local data center to the cloud– requires reconfiguration of middleboxes. These issues are even worse in networks with 100s of middleboxes [8]. We argue that configuration of both middlebox traversals and middlebox functionality should be unified under a single centralized control plane (Section 2). This (i) enables easy verification of objectives, (ii) decreases errors due to distributed configurations and topology changes, and (iii) permits seamless migration of middleboxes between different underlying substrates (e.g., local data center to cloud). There are several challenges and trade-offs in designing a centralized unified middlebox control plane (Section 3). First, the examination, modification, and forwarding applied to specific traffic subsets should be specifiable in a flexible, concise manner. Second, the objectives need to be reconciled with the constraints of the underlying infrastructure.